Shape Up
Foreword
ソフトウェア開発は間違った方法でやると疲弊する
理不尽なプロジェクト、全員がイライラして納品するよりも死んだ方がマシ
正しい実行とはなにか
Basecampではスプリントやスタンドアップもしないしスクラムとかアジャイルとかもやんない
-.icon
Intro
2003/07 ~ 2004/02まで、DHHは10h/weekしか働いていなかった
プロダクトチームは4倍になった。全員リモートだった。何をしているのかを伝えるための「言語」と「構造」が必要だった
チームが着手する前に前もって行うデザイン仕事を表現する方法を考えてて、"Shaping"とした。
Six week cycles
全ての決定は6週間でプロダクトを前進させるという考えに基づいていて、時間をマイクロマネジメントするということは考えていない
Shaping work
プロジェクトは適度な抽象度で定義される。チームが何をすればいいのかわかる程度に十分に具体的だけど、面白いところは自分たちで取り組めるくらいの余白は残す。
Shapingするときは、見積もりを重視するのではなく、興味とか欲求(appetite)を重視する
「どれくらいかかる?」ではなくて「どれくらい使いたい?」「どれくらいの価値があるのか?」
Making teams responsible
Targeting risk
プロジェクトをタイムボックスに入れる前に、いくつかのオープンな質問を解決しておくことで、"Shaping"プロセスのリスクを低減できる。
6週間は「サーキットブレーカー」になっていて、これ以上延長しない。
-.icon
Wireframes are too concrete
デザインリーダーがワイヤーフレームやよくできたモックアップを突然作ってしまうのは、あまりに早い段階で詳細を定義している
デザイナーが創造性を発揮できる余地がなくなっちゃう
設計のオーバースペック化は見積もりのミスに繋がる
インタフェースを作ると複雑さや実装の詳細が隠れている場合があって、それを後々解決しないといけなくなる。
Words are too abstract
プロジェクトの定義が数語で書いてあってもなんなのかわからない。
トレードオフを決めるのに重要な情報がない。何をやればいいのか、何は除いてもいいのかわからない Case study: The Dot Grid Calendar
昔カレンダー機能を作ったけど10%しか使っていなかった
6weekの1サイクルで何か満足いくものが作れるなら、やりたい。
6週間の作業では1/10くらいしか作れないので、どうやってそれを作るか?を考えた
https://gyazo.com/2535f88f98a91c7bfdc0d87d450a6900
https://gyazo.com/431c4f8b43e51e4ca1989d66d5a275ce
Property 1: It's rough
Shaping中の作業は大雑把。誰が見ても未完成だとわかる。
自分たちの貢献はどこへ向ければいいのか、余白がわかる。細かすぎる仕事・早すぎる仕事は誰もが間違った詳細にコミットしてしまう。
Property 2: It's solved
仕事は個々のタスクには分割されていないけど、全体的な解決策は提示されている。
想定外のことは起きるかもしれないけど、どうすればいいかの方向性は示されている。
Property 3: It's bounded
the roughness leaves room for the team to resolve all the details, while the solution and boundaries act like guard rails
荒さは全ての残りの詳細をチームが解決する余地を残し、解決策と境界がガードレールみたいな役割を果たす
チームは多く作りすぎたり、さまよったり、行き詰まったりすることがないようにする
Who shapes
Shapingは閉鎖的で創造的なプロセス。
誰かに聞いてみたり、1人でスケッチしたり、率直に話して。。。
いろんなポジションからアプローチする、プライベートでラフな仕事
Two tracks
Shaping / Building
Steps to shaping
Set boundaries
Rough out the elements
Address risks and rabbit holes
Write the pitch